home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-tpix-tcpopt-00.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
11KB
|
386 lines
TP/IX Working Group R. L. Ullmann
Internet Draft Process Software Corporation
June 30, 1993
TCP version 7 options
1 Status of this Memo
This memo describes experimental option definitions for use with the
TP/IX version 7 TCP.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. (Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Ullmann DRAFT: expires December 29, 1993 [page 1]
Internet draft TCP version 7 options June 30, 1993
2 Contents
1 Status of this Memo . . . . . . . . . . . . . . . . 1
2 Contents . . . . . . . . . . . . . . . . . . . . . . 2
3 Introduction . . . . . . . . . . . . . . . . . . . . 3
4 Selective Acknowledgement . . . . . . . . . . . . . 3
5 Time Stamp . . . . . . . . . . . . . . . . . . . . . 3
6 Record Mark . . . . . . . . . . . . . . . . . . . . 4
7 References . . . . . . . . . . . . . . . . . . . . . 6
8 Author's Address . . . . . . . . . . . . . . . . . . 6
Ullmann DRAFT: expires December 29, 1993 [page 2]
Internet draft TCP version 7 options June 30, 1993
3 Introduction
This memo presents several options for version 7 of the TCP. Two of
them provide for the extensions defined by the TCP Large Windows
project not covered in the basic field definitions. The other option
helps provide some of the semantics expected of the transport layer by
OSI applications, and may be useful to other applications defined on
the TCP.
4 Selective Acknowledgement
The selective acknowledgement (SACK) option (type = 4) indicates that
some block of data, not "connected" to the left (start) edge of the
TCP window has been received. It need not be transmitted again by the
other TCP and will be acknowledged by the TCP sending the SACK option
in the normal way when the window edge arrives at the first sequence
number in the block.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = 4 | length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ start sequence number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ end sequence number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This acknowledges receipt of bytes between (start) and (end-1). If
end is equal to or less than start in sequence space, the option is
meaningless, and must be ignored.
The SACK option should not be used to acknowledge the FIN (or SYN)
sequence number. A selective acknowledgement that attempts to
acknowledge the FIN sequence number should be ignored.
The selective acknowledgement option may occur more than once in a TCP
segment, acknowledging receipt of more than one block of data. A
block may represent more than one consecutive segment. It is probably
unreasonable to expect the other TCP to use a SACK that acknowledges
less than a full segment.
5 Time Stamp
The time stamp option (type = 5) is used for enhanced measurement of
the round-trip delays of the network path being used for a TCP
connection. It contains a timestamp value selected by the sending
TCP, and a copy of the (usually) most recently-received timestamp from
the other TCP.
Ullmann DRAFT: expires December 29, 1993 [page 3]
Internet draft TCP version 7 options June 30, 1993
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = 5 | length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp value +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Echoed timestamp reply +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The timestamp field is only valid when its value is non-zero.
The reply field is only valid when the ACK flag is set in the TCP
header, and the value of the reply field is non-zero. When the ACK
flag is not set, the timestamp reply field (if the option appears)
must be zero.
Please refer to [RFC1323] for the precise use of this option in
round-trip measurements. The version 7 TS option is not used for the
PAWS mechanism described therein; the 64-bit sequence space is not
expected to wrap within a connection.
The exact semantics of the timestamp values used by the (remote) TCP
are not specified; the frequency, resolution, and stabilty of the
remote clock are not used by the local TCP. The local TCP should only
copy specific remote TS values into the echo-reply field. ([RFC1323]
specifies that the TS values must be monotonically non-decreasing, for
use with PAWS; this may be unnecessary here.)
6 Record Mark
The record mark option (type = 6) indicates the boundary of an
application record. The record mark is constructed by the TCP service
interface at the sender, and passed to the receiver's service
interface. It is not used directly by the TCP, except that the TCP
may use record marks as hints to where segments might be divided for
maximum performance.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = 6 | length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ mark sequence number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ullmann DRAFT: expires December 29, 1993 [page 4]
Internet draft TCP version 7 options June 30, 1993
The mark sequence number identifies the first octet of the following
record. This is consistant with the definition of the acknowlegement
field, which identifies a point "in between" octets by specifying the
number of the following octet.
The mark must point somewhere within the segment carrying the option,
i.e. it must be between the segment sequence number and the sequence
number plus the segment size, inclusive. Receivers may ignore record
mark options that point outside the segment.
The option may occur any number of times within one segment.
There is an implicit record mark at sequence SYN+1, and an implicit
mark at sequence FIN. (And remember that these may be the same
point.) A sending TCP may prefer to send an explicit mark at SYN+1,
possibly on the SYN segment itself; this allows early indication to
the receiver's application that record marking is available and will
be used.
Note that to be useful when a record is sent in exactly one segment,
the option marking the record boundary should point at the end of the
segment. (I.e. the record mark between two records should be sent
with the first record, not the second.) If this is not done, the
reciever would have to wait for a subsequent record before being able
to pass the first to the application.
There are no zero-length records. The record mark itself does not
have a sequence number; there is no way to distinguish a repeat of a
record mark (in, for example, a segment containing retransmitted data)
and thus no way to deliver two or more record marks at the same
sequence number.
Finally, it may be desireable for the TCP to request network layer
conversion prohibition (IP Don't Convert option) to prevent loss of
record marking if the network route changes to traverse version 4
systems. (Another possibility is to redefine the high bit of the
option type field to be an indicator that the conversion must fail if
the option is not translatable; this feature was in a prior version of
TP/IX. If such a failure occured, the datagram would be returned with
ICMP conversion failed/code 11.)
An earlier version of TP/IX specified a TCP flag (M), indicating "more
data" in the style of (e.g.) X.25. When the M flag was clear, the
segment was the last (or only) part of the application record; when
set, it indicated that there was more data to come. The flag method
was discarded in favor of the option because it added constraints to
the TCP that are undesirable. Like X.25 and OSI TP0, the flag permits
a TSDU (Transport Service Data Unit) to span multiple TPDUs, but does
not permit the coelescing of multiple small TSDUs into one TPDU, and
thence one network datagram. In the TCP architecture, segmentation is
entirely in the control of the TCP, and the record marking is only of
interest to the application.
Ullmann DRAFT: expires December 29, 1993 [page 5]
Internet draft TCP version 7 options June 30, 1993
7 References
[RFC1323] V. Jacobson, R. T. Braden, D. A. Borman. TCP extensions
for high performance. May, 1992.
[RFC1475] Robert Ullmann. TP/IX: The Next Internet. Process
Software Corporation. June, 1993.
[RFC1476] Robert Ullmann. RAP: Internet Route Access Protocol.
Process Software Corporation. June, 1993.
8 Author's Address
Robert Ullmann
Process Software Corporation
959 Concord Street
Framingham, MA 01701
USA
Phone: +1 508 879 6994 x226
Email: Ariel@Process.COM
Ullmann DRAFT: expires December 29, 1993 [page 6]